home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 725 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.2 KB

  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: OS features
  5. Date: 9 Jan 1996 02:16:05 +0100
  6. Organization: dis-
  7. Message-ID: <4csfkl$oco@serpens.rhein.de>
  8. References: <92747544038@PAPA.NORTH.DE> <4b3h9s$1st@alterdial.UU.NET> <2152.6561T63T2136@cycor.ca> <4b7i18$si1@vixen.cso.uiuc.edu> <oj6raxxrr0o.fsf@hpsrk.fc.hp.com> <13213431@sourcery.han.de> <4cp0un$cve@serpens.rhein.de> <4cs4ji$rou@news.mpd.tandem.com>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. Joseph Crowe <jcrowe> writes:
  12. >   I'm struggling to understand what you mean by the above paragraph.  I don't
  13. >find it at all desirable to have a system where an interface library can
  14. >arbitrarily corrupt data structures in user task space.  Could you relate this
  15. >concept to a more concrete example?
  16.  
  17. Think about the UNIX kernel. No user task is protected from the kernel, the
  18. kernel can access everything. This is only a small risc because the kernel
  19. has only few bugs.
  20.  
  21. So the design for memory protection doesn't need to protect arbitrary
  22. objects. You just have to protect the good guys (well debugged libraries)
  23. against the bad guys (arbitrary user code).
  24.  
  25. >   Are you saying that some sort of object server should be allowed to
  26. >arbitrarily corrupt an instantiation of a client or even an inherited object in
  27. >the client tasks memory area?  Not in any OS I'd ever own.
  28.  
  29. It is basically in every OS that provides protection. With UNIX the
  30. whole system library (aka the kernel) can corrupt user programs.
  31. Other systems use several layers of protection to minimize the riscs.
  32.  
  33. >   With demand paged VM, there's often multiple sizes of allocation units, at
  34. >least, once you leave user space.
  35.  
  36. Huh ? The "allocation" unit is a page. And a page is usually of constant
  37. size for the whole system.
  38.  
  39. >algorithm.  Most shared library implementations in UNIXland will not even bring
  40. >in a single page of a shared library until a page fault occurs attempting to
  41. >access and instruction from that library.
  42.  
  43. Hasn't to do anything with fragmentation though.
  44.  
  45.  
  46. -- 
  47.                                 Michael van Elst
  48.  
  49. Internet: mlelstv@serpens.rhein.de
  50.                                 "A potential Snark may lurk in every tree."
  51.